1. Field of the Invention
The present invention relates to HTTP (Hypertext Transfer Protocol) session technology, and in particular, relates to a method and a system for processing an HTTP request.
2. Description of the Related Art
The HTTP hypertext transfer protocol is a one-way protocol. One-way protocol means that according to the HTTP protocol, a server cannot initiate sending a connection request to a client, but can only passively wait for and respond to an HTTP request issued from the client. Since HTTP itself does not support saving a client's state information at a server, a state management mechanism such as a session mechanism, is introduced to maintain a session state between the server and the client.
Introduction of the session mechanism overcomes some limitations of HTTP and enables a relationship between respective HTTP requests to be maintained at the client and the server. Based on the session mechanism, when the client is first connected to the server, an HTTP session is established at the server and variants related to the session are saved, while an HTTP session id is generated to identify variants of the session. Next, the server will instruct a browser, in an HTTP response, to generate, at the client, a “Cookie” corresponding to the HTTP session id. A Cookie is a small segment of text stored by the server in the client. During the session period, each time an HTTP request is issued to the server through the browser, a session id contained in the Cookie will be included in the HTTP request to be sent to the server, such that the server can identify the session and obtain variants related to the session.
However, in the related art, it generally occurs that in an HTTP session, running a plurality of application instances corresponding to a same application is typically required. Since the domain names for a plurality of application instances of a same application are all identical, in this case, for all HTTP requests requesting accessing different application instances, a server of the application will generate a same session id. The plurality of application instances share a common HTTP session. At this time, problems such as data confusion, data loss, and data error may occur, which seriously affect user experience.
FIG. 1 shows an example of a conventional application environment having a plurality of application instances and likely causing problems. As shown in FIG. 1, in this example, there are two servers, one being a portal server 110, and the other being a SaaS (Software As a Service) settlement server 120.
A user may log on to the portal server 110 through a browser with his own username and password, and then the user enters into a page 100. The page 100 comprises three user interface components, such as inline frame (IFrame) 101, IFrame 102, and IFrame 103. IFrame 101, IFrame 102, and IFrame 103 correspond to a same settlement application, thus their access points (IP addresses) are identical. However, a service instance corresponding to the IFrame 101 is Company A's master data and a service instance corresponding to the IFrame 102 is Company B's master data, while a service instance corresponding to the IFrame 103 is Company C's master data.
In the left bottom corner of FIG. 1, there is an example of Cookie 104 when all of the three IFrames are open. From this example, it may be seen that there are two session ids in the Cookie 104, such as, SESSIONID 105 and SESSIONID 106. The SESSIONID 105 is used in communication with the portal server 110, and meanwhile, variant information 111 corresponding to the SESSIONID 105 is saved in the portal server 110. The SESSIONID 106 is used in communication with the settlement server 120, and meanwhile, variant information 121 corresponding to the SESSIONID 106 is saved in the settlement server 120.
According to the related art though there are three application instances corresponding to the settlement application. In this case, it is SESSIONID 106 that is used in communication with the settlement server 120, because the application server (i.e., settlement server) only assigns one HTTP session id such as SESSIONID 106 to the HTTP requests for accessing the three application instances. Since with the SESSIONID 106, it is impossible to distinguish which application instance is in use, problems always occur, because after operation to Company A's master data, a session variant as stored at the settlement server 120 and is a value related to Company A.
After operation to Company B's master data, a session variant as stored at the settlement server 120 may be a value related to Company B. Thus, after operation to Company B's master data, if an HTTP request for accessing Company A is submitted again to return to view Company A's master data, what is actually viewed at this point might be master data related Company B. This causes great confusion and may even cause data error.
In order to solve this problem, in some applications, there is particularly designed a mechanism which forbids the operation when detecting a requirement for instantiating a plurality of service instances of a same application during a same HTTP session period. In other words, if data of another company is to be processed, the current HTTP session must be terminated to reconnect to the server. This manner, though it avoids data confusion and data error, is quite troublesome, which brings bad experience to users. Thus, this solution cannot satisfy commercial demands at all.
There is another solution which only guarantees that the data of the last accessed service instance is correct. This solution is simple, but users cannot view master data of previous application instances, which still causes great inconvenience to users.
FIG. 1 shows that the settlement server and the portal server are located in an environment of a same domain. These problems still occur when the settlement server and the portal server are located in different domains.